1. Field of the Invention
Embodiments of the present invention generally relate to improving the time-offset accuracy between the transmitter and receiver paths over data networks and, more specifically, to network time protocol precision timestamping service.
2. Description of the Related Art
In many communications applications, each element in a network has its own internal clock running independently of the other clocks in the network. Where the networks are synchronous networks, such as in many telecommunications applications and in high speed wide area networks, these clocks must be synchronized to the server. In legacy telecommunications networks, network elements utilized “TDM” links, such as T1 and SONET, which are inherently capable of carrying timing information from server to client at the physical layer. However, it is generally agreed that next generation networks will be based on a packet-switched infrastructure and, therefore, packet-based methods for transporting timing information will be used. One of the methods for synchronizing clocks in packet-switched data networks is Network Time Protocol (NTP).
Commercial NTP servers typically employ highly accurate hardware based clocks, which are disciplined to the external standards. In turn, NTP clients send carefully crafted packets to NTP servers and analyze their replies in order to determine the offset of the client clock relative to the server clock. A typical packet contains four timestamps. The timestamps are designed to precisely time the transmit and receive paths of the client/server time packet interchange so that the roundtrip delay between the endpoints and the offset of the client clock may be calculated. However, despite the high accuracy of the hardware based clock at the NTP server, if there are any inaccuracies associated with the timestamping function in the NTP server, the NTP server introduces errors into the timestamps provided to the client. Subsequently, these errors propagate to the client clock and compromise proper correction of the client clock.
Most of the inaccuracies within the timestamps created by the NTP server are introduced by various layers of software, including device drivers, network stacks, and the increasing use of non-real-time operating systems. This is illustrated in FIG. 1, conceptually demonstrating a packet timestamping flow in a typical NTP system 100, according to prior art. Most of existing NTP servers include systems such as the NTP system 100. Typically, a timestamp in a packet is supposed to reflect the instant of the arrival or departure referenced to the physical layer interface. With reference to FIG. 1, the physical layer is associated with an Ethernet PHY 110. In this case, the time-of-arrival refers to the instant the first (or the designated) bit of each of the incoming packets traverses the boundary between the external environment (not shown) and the Ethernet PHY 110. Likewise, the time-of-departure is meant to be the instant when the first (or the designated) bit of each of the outgoing packets crosses the said boundary between the Ethernet PHY 110 and the external environment.
As illustrated in FIG. 1, when an incoming packet 102 arrives at the NTP system 100, it passes through several entities: the physical layer associated with the Ethernet PHY 110, an Ethernet Media Access Controller (MAC) 120, operating system (O/S) services 130, an NTP application 140. Some of these entities are physical (such as the Ethernet MAC 120) and some are logical (such as the O/S services 130). A path for the incoming packet 102 is shown with arrows 112, 122, and 132. As shown with an arrow 142, the NTP application 140 requests a timestamp from a hardware clock 150 to be recorded in the incoming packet 102 only after the incoming packet 102 traverses the Ethernet PHY 110, the Ethernet MAC 120, and the O/S services 130 and actually reaches the NTP application 140 (such a timestamp is referred to herein as a “receive timestamp”). Upon receiving a request from the NTP application 140, the hardware clock 150 sends current time value as the receive timestamp, illustrated as timestamps 144. Thus, there is a delay, with a significant random component, between the actual time-of-arrival at the NTP system 100 and the time when the NTP application 140 actually reads the hardware clock 150 to ascertain the value for the receive timestamp.
A similar situation occurs for an outgoing packet 104 leaving the NTP system 100. The NTP application 140 reads current time value from the hardware clock 150 and inserts that value as a timestamp in the appropriate field within the outgoing packet 104 (such a timestamp is referred to herein as a “transmit timestamp”). After the transmit timestamp is inserted, the NTP application 140 launches the outgoing packet 104 on a path shown by arrows 134, 124, and 114. Again, since the outgoing packet 104 must first traverse the O/S services 130, the Ethernet MAC 120, and the Ethernet PHY 110, there is a delay, with a significant random component, between the instant when the transmit timestamp was obtained from the hardware clock 150 and the actual time-of-departure from the NTP system 100. Consequently, inaccurate receive and transmit timestamps propagate from the NTP system 100 to the client clock and set the baseline error for time keeping and rate keeping at the client clock.
As the foregoing illustrates, what is needed in the art is an improved NTP timestamping method which could provide more precise and stable measurement of the transition of the NTP packets.